通用/[筆記]Open Source License

[討論]菜鳥專屬,開源授權的各種實務上的意義

備註:Michael_LI  開放式筆記

   有別人要填寫也沒問題,只不過格式本人會整理成統一格式。

工具:純文字檔案,瀏覽器,KKMAN、hackpad+E-Mail

搜尋

  Google:open surce 授權

  

-1-

TXT 起始於

開放原始碼 (開源碼, open source) 當初被設計出來的理念非常崇高,

甚至可以說作者是帶著理想而設計出這樣子的授權(協議, License)。

相信大家或多或少都聽說過開放原始碼的好處,

藉由每個人讓自己的程式碼透過網路在世界自由流通,

讓程式可以被全世界有著同樣理念的 programmer 檢視、修正及改進,

將可以讓程式與軟體的撰寫、修正更快、更加安全,

規模也不再限於單人的能力,而可以發展出更大的系統。

然而雖然每個人都想自由地分享各自的程式,

但其實大家背後真正的想法還是會不同,

例如有人什麼也不想要,只要這個程式能更好更多人用即可;

有的則想要留下名聲,讓每個使用的人都知道原作者是誰;

有的則又規定這套程式一定不可以被拿來賣錢等等。

因為有太多這些複雜的因素,加上 programmer 又很討厭法律事,

為了讓開放原始碼可以更簡單更容易,

便開始有個人、單位或組織建立了開源授權協議 (Open Source License),

目前常用的大多已經過 Open Source Initiative 核準,

核準後的授權協議書全文都可以在 Open Source Licenses 上找到。

若不熟悉英文,或覺得看英文加法律實在太痛苦了!

台灣也有個自由軟體鑄造場 (Open Source Software Foundry,簡稱 OSSF)

網站中針對常見的 Open Source License 都有全文翻譯,大家可以去看看。

目前最常見也最常被討論及使用的 License 有 GPL, LGPL, BSD, Apache, MIT 等。

GNU General Public License 2.0(GPL)

GPL 是 License 中最具開放原始碼精神的,

然而他在崇尚自由之時,也要求(強迫)所有人一起崇尚自由,

病毒式的感染、傳染常被用來形容 GPL,

因為所有只要「引用/修改/衍生自 GPL 授權程式碼的軟體也必須採用GPL授權」

且要求未來所有的使用者、開發者也必須採用同樣的條款。

基於這樣的限制,所以商業軟體或是不打算公開程式碼的軟體和 GPL不可以有任何牽連,

否則受到感染後就只能依 GPL 規定開放原始碼了。

著名的GPL自由軟體包括Linux核心和GCC等。

GNU Lesser General Public License 2.1(LGPL)

由於 GPL 的條款實在是太嚴格了,間接也會影響到程式碼的被採用率,

因此後來也出現了針對放寬 GPL 部份限制後的授權版本,即 LGPL,

二者最大的差異是在「引用」的部份。

若只在程式中引用了採用 LGPL 授權程式的函式庫,

而沒有針對該程式進行修改或衍生,

則依據 LGPL 的條款,引用函式庫的程式便不需要公開程式碼。

和 GPL 比起來,在 LGPL 的授權下,

商業軟體可以引用 LGPL 的函式庫,藉由函式庫提供的功能來開發軟體,

不過對於剛剛提到的「修改/衍生」LGPL 授權的部分,

則同樣必須採用 LGPL 的授權,同樣需要公開原始碼。

著名的 LGPL 自由軟體有 OpenOffice.Org。

至於其他三種:

BSD License(BSD)MIT License(MIT)Apache License 2.0(Apache 2.0)

都是股勵原始碼分享、允許代碼修改、衍生再發佈(開源或商業軟體皆可),

並且注重原始作者著作權的授權,通常需要附上原始授權及部份聲明文件,

但修改者可適度修改所採用的授權內容以符合自身需求。

至於其中的區別,再看看有沒有人可以補充說明,感謝 ^^

關鍵字:開放原始碼, 開源, 授權, Open Source License, 比較, 說明, 介紹, GPL, LGPL, BSD, Apache, MIT, 軟體, 採用

參考資料:

-1.1-

TXT 起始於

當Adobe、Microsoft、Sun等一系列巨頭開始表現出對"開源"的青睞時,"開源"的時代即將到來!

現今存在的開源協議很多,而經過Open Source Initiative組織通過批准的開源協議目前有58種(http://www.opensource.org/licenses/alphabetical)。我們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批准的協議。如果要開源自己的代碼,最好也是選擇這些被批准的開源協議。

這裡我們來看四種最常用的開源協議及它們的適用範圍,供那些準備開源或者使用開源產品的開發人員/廠家參考。

BSD開源協議(original BSD license、FreeBSD license、Original BSD license)

BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以"為所欲為",可以自由的使用,修改源代碼,也可以將修改後的代碼作為開源或者專有軟件再發佈。

但"為所欲為"的前提當你發佈使用了BSD協議的代碼,或則以BSD協議代碼為基礎做二次開發自己的產品時,需要滿足三個條件:

如果再發佈的產品中包含源代碼,則在源代碼中必須帶有原來代碼中的BSD協議。

如果再發佈的只是二進制類庫/軟件,則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議。

不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。

BSD 代碼鼓勵代碼共享,但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發佈代碼,也允許使用或在BSD代碼上開發商業軟件發佈和銷售,因此是對 商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議,因為可以完全控制這些第三方的代碼,在必要的時候可以修改或者二次開發。

Apache Licence 2.0(Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0)

Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似,同樣鼓勵代碼共享和尊重原作者的著作權,同樣允許代碼修改,再發佈(作為開源或商業軟件)。需要滿足的條件也和BSD類似:

需要給代碼的用戶一份Apache Licence

如果你修改了代碼,需要再被修改的文件中說明。

在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協議,商標,專利聲明和其他原來作者規定需要包含的說明。

如果再發佈的產品中包含一個Notice文件,則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可,但不可以表現為對Apache Licence構成更改。

Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發佈/銷售。

GPL(GNU General Public License)

我們很熟悉的Linux就是採用了GPL。GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用,但不允許修改後和衍生的代 碼做為閉源的商業軟件發佈和銷售。這也就是為什麼我們能用免費的各種linux,包括商業公司的linux和linux上各種各樣的由個人,組織,以及商 業軟件公司開發的免費軟件了。

GPL協議的主要內容是只要在一個軟件中使用("使用"指類庫引用,修改後的代碼或者衍生代碼)GPL 協議的產品,則該軟件產品必須也採用GPL協議,既必須也是開源和免費。這就是所謂的"傳染性"。GPL協議的產品作為一個單獨的產品使用沒有任何問題, 還可以享受免費的優勢。

由於GPL嚴格要求使用了GPL類庫的軟件產品必須使用GPL協議,對於使用GPL協議的開源代碼,商業軟件或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。

其它細節如再發佈的時候需要伴隨GPL協議等和BSD/Apache等類似。

LGPL(GNU Lesser General Public License)

LGPL是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟件必須採用GPL協議不同。LGPL允許商 業軟件通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟件的代碼。這使得採用LGPL協議的開源代碼可以被商業軟件作為類庫引用並發布和 銷售。

但是如果修改LGPL協議的代碼或者衍生,則所有修改的代碼,涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議。因此LGPL協議的開源代碼很 適合作為第三方類庫被商業軟件引用,但不適合希望以LGPL協議代碼為基礎,通過修改和衍生的方式做二次開發的商業軟件採用。

GPL/LGPL都保障原作者的知識產權,避免有人利用開源代碼複製並開發類似的產品

MIT(MIT)

MIT是和BSD一樣寬範的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版裡包含原許可協議的聲明,無論你是以二進制發佈的還是以源代碼發佈的.

-2-

授權(License)的種類

GPL

GNU General Public License主要是由Linux陣營的開源軟體開發者為主在使用的,它有幾個特色

散佈與修改

如同我們前面提到的散佈,最重要的重點是,如果你改了程式,而又要散佈程式,那麼你在散佈的同時也要把你修改的部份也公開出來,例如

修改了原始碼後拿來販售

修改了原始碼後編成執行檔供別人使用

上列行為都扯到了散佈,因此如果你程式有修改,你不能只給別人執行檔,要連改的部份一起開源出來,這條款的目的主要是在於GNU的社群,希望強迫使用者能回饋社群,因為一但你改了程式,想拿來賣錢,就得公開出來,避免有人改進了程式,拿來販售,但沒有公開程式的問題

當然,如果你的程式只是自己使用,或是公司內部使用,那麼你修改了程式但因為沒有散佈的問題,所以修改的部份也不用因此公開,還有一種情況是,你使用GPL授權的程式放在伺服器上提供服務,因為這過程沒有重新散佈,所以也不會有問題

除了修改以外,還有一個特性,就是病毒的感染性,除了修改程式,如果GPL的原始碼是函式庫,而你的程式連結了GPL授權的程式,不管是靜態連結或動態連結,都會因此被GPL感染,一但你要散佈你的程式,因為用了GPL的函式庫,因此你的主程式也被感染,變成你要把你的主程式一起開源出來,就因為這特性替GPL贏得了「病毒授權」的美名,就跟T病毒一樣,被感染了就會變成殭屍

就因為這樣病毒的特性,讓很多人又愛又恨,很多商業軟體想用某些開源的函式庫,但因為那些函式庫如果是GPL授權,會導至他們的產品本身也受到感染,而因此無法使用,變成非GPL和GPL這兩種可能性,除此之外,有些廠商為了避免被GPL感染,會用一些比較特別的手法來避開

因為這樣感染的特性,加上如此不自由的特質,使得很多可以用上GPL的場合卻因為感染性而無法達成,為了能解決感染的問題,它有推出另一種弱化版的GPL,叫LGPL (Less Generic Public Licence),這個授權大致上和GPL是一樣的,差別就在於上面提到的連結受感染的問題,連結LGPL的函式庫並不會受到感染,如此一來就算是商業軟體也能安心地使用LGPL的函式庫

接著還有它的排它性,因為授權有很多種,GPL規定它的授權條款不能被修改,這表示你修改了程式要散佈被強迫要開源的話,你也只能選擇GPL的授權,除非你是原作者

你覺得GPL很不自由嗎? 事實上他們覺得GPL還不夠嚴格,正因為GPL陣營的人認為像Google之流的廠商,用了GPL的程式提供服務,不用公佈修改的部份,因此覺得心癢癢的,為此甚至增加了AGPL,更加嚴格的GPL,他的重新散佈的定義,擴增為包括提供服務,因此即使你用了AGPL的程式提功服務,沒有轉交程式給他人,就AGPL的定義,這就算是重新散佈,然而使用AGPL授權的程式其實非常少,像是MongoDB就是使用AGPL授權,正因為LGPL/GPL/AGPL強烈的限制特性,反而使它成為商業軟件開源的最愛授權,對手要修改販授的話也得公開,不想公開的話就得買另外的授權,這就是常見的雙授權商業模式,因此我個人喜歡戲稱GPL為 “商業友善授權”

類BSD

如果說GPL是邪惡的病毒授權,那麼類BSD就是自由又開放的授權,相較於GPL相當害怕別人用了GPL的程式不回饋,類BSD就大方許多,它最主要的條款就是,當你散佈修改過的類BSD授權下的程式,一樣不管是二進制的執行檔或原始碼,你要盡的義務就只有記得要把類BSD的授權一起轉交給別人就可以了,包含原作的姓名你也得一併加進去,不能自行亂改

舉個例子,你改了一個BSD授權的應用程式,你想編譯好成執行檔放到網路上供人下載,可以,只要連著當初的BSD授權一起散佈即可,不必把你改的部份也公開出來,因此你可以安心的用BSD授權的函式庫來寫商業軟體

下面的例子都是不違反BSD授權的做法

修改BSD授權的程式編譯成執行檔來賣,只提供執行檔而非原始碼給使用者,原始的BSD授權條款也得一併給使用者

連結BSD授權的函式庫,主程式只提供執行檔進行販售,原始的BSD授權條款也得交給使用者

而下面這些例子可能會違反BSD授權

重新散佈BSD授權的程式,竄改並宣稱自己才是原作者

散佈BSD授權的程式,但不附帶BSD授權條款

那你可能會問附帶BSD授權條款是怎樣辦到,很簡單,通常都只是一個LICENSE.txt檔案夾在壓縮檔裡之類的即可

而類BSD在此只是通稱,因為有很多授權都有這類主要的特性,大約列出常見的,像是

其中zlib最為自由,只要求不能亂改作者,不能聲稱修改的版本才是原始版本,以及不能移除授權,也就是散佈時一樣要附帶zlib授權,除此之外還有很多非常多種的授權,這只是常見的幾種,只要你看見他有寫 “BSD-like”,通常就是指它的特色跟上面描述的差不多,有些專案會特別量身訂作他們自己的授權,但精神大多都會跟這些主流授權差不多